home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxx / rfc920 < prev    next >
Text File  |  1995-07-25  |  28KB  |  799 lines
  1.  
  2.  
  3. Network Working Group                                          J. Postel
  4. Request for Comments: 920                                    J. Reynolds
  5.                                                                      ISI
  6.                                                             October 1984
  7.  
  8.                           Domain Requirements
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    This memo is a policy statement on the requirements of establishing a
  14.    new domain in the ARPA-Internet and the DARPA research community.
  15.    This is an official policy statement of the IAB and the DARPA.
  16.    Distribution of this memo is unlimited.
  17.  
  18. Introduction
  19.  
  20.    This memo restates and refines the requirements on establishing a
  21.    Domain first described in RFC-881 [1].  It adds considerable detail
  22.    to that discussion, and introduces the limited set of top level
  23.    domains.
  24.  
  25. The Purpose of Domains
  26.  
  27.    Domains are administrative entities.  The purpose and expected use of
  28.    domains is to divide the name management required of a central
  29.    administration and assign it to sub-administrations.  There are no
  30.    geographical, topological, or technological constraints on a domain.
  31.    The hosts in a domain need not have common hardware or software, nor
  32.    even common protocols.  Most of the requirements and limitations on
  33.    domains are designed to ensure responsible administration.
  34.  
  35.    The domain system is a tree-structured global name space that has a
  36.    few top level domains.  The top level domains are subdivided into
  37.    second level domains.  The second level domains may be subdivided
  38.    into third level domains, and so on.
  39.  
  40.    The administration of a domain requires controlling the assignment of
  41.    names within that domain and providing access to the names and name
  42.    related information (such as addresses) to users both inside and
  43.    outside the domain.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Postel & Reynolds                                               [Page 1]
  57.  
  58.  
  59.  
  60. RFC 920                                                     October 1984
  61. Domain Requirements
  62.  
  63.  
  64. General Purpose Domains
  65.  
  66.    While the initial domain name "ARPA" arises from the history of the
  67.    development of this system and environment, in the future most of the
  68.    top level names will be very general categories like "government",
  69.    "education", or "commercial".  The motivation is to provide an
  70.    organization name that is free of undesirable semantics.
  71.  
  72.    After a short period of initial experimentation, all current
  73.    ARPA-Internet hosts will select some domain other than ARPA for their
  74.    future use.  The use of ARPA as a top level domain will eventually
  75.    cease.
  76.  
  77. Initial Set of Top Level Domains
  78.  
  79.    The initial top level domain names are:
  80.  
  81.       Temporary
  82.  
  83.          ARPA  =  The current ARPA-Internet hosts.
  84.  
  85.       Categories
  86.  
  87.          GOV  =  Government, any government related domains meeting the
  88.                  second level requirements.
  89.  
  90.          EDU  =  Education, any education related domains meeting the
  91.                  second level requirements.
  92.  
  93.          COM  =  Commercial, any commercial related domains meeting the
  94.                  second level requirements.
  95.  
  96.          MIL  =  Military, any military related domains meeting the
  97.                  second level requirements.
  98.  
  99.          ORG  =  Organization, any other domains meeting the second
  100.                  level requirements.
  101.  
  102.       Countries
  103.  
  104.          The English two letter code (alpha-2) identifying a country
  105.          according the the ISO Standard for "Codes for the
  106.          Representation of Names of Countries" [5].
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Postel & Reynolds                                               [Page 2]
  114.  
  115.  
  116.  
  117. RFC 920                                                     October 1984
  118. Domain Requirements
  119.  
  120.  
  121.       Multiorganizations
  122.  
  123.          A multiorganization may be a top level domain if it is large,
  124.          and is composed of other organizations; particularly if the
  125.          multiorganization can not be easily classified into one of the
  126.          categories and is international in scope.
  127.  
  128. Possible Examples of Domains
  129.  
  130.    The following examples are fictions of the authors' creation, any
  131.    similarity to the real world is coincidental.
  132.  
  133.    The UC Domain
  134.  
  135.       It might be that a large state wide university with, say, nine
  136.       campuses and several laboratories may want to form a domain.  Each
  137.       campus or major off-campus laboratory might then be a subdomain,
  138.       and within each subdomain, each department could be further
  139.       distinguished.  This university might be a second level domain in
  140.       the education category.
  141.  
  142.       One might see domain style names for hosts in this domain like
  143.       these:
  144.  
  145.          LOCUS.CS.LA.UC.EDU
  146.          CCN.OAC.LA.UC.EDU
  147.          ERNIE.CS.CAL.UC.EDU
  148.          A.S1.LLNL.UC.EDU
  149.          A.LAND.LANL.UC.EDU
  150.          NMM.LBL.CAL.UC.EDU
  151.  
  152.    The MIT Domain
  153.  
  154.       Another large university may have many hosts using a variety of
  155.       machine types, some even using several families of protocols.
  156.       However, the administrators at this university may see no need for
  157.       the outside world to be aware of these internal differences.  This
  158.       university might be a second level domain in the education
  159.       category.
  160.  
  161.       One might see domain style names for hosts in this domain like
  162.       these:
  163.  
  164.          APIARY-1.MIT.EDU
  165.          BABY-BLUE.MIT.EDU
  166.          CEZANNE.MIT.EDU
  167.          DASH.MIT.EDU
  168.  
  169.  
  170. Postel & Reynolds                                               [Page 3]
  171.  
  172.  
  173.  
  174. RFC 920                                                     October 1984
  175. Domain Requirements
  176.  
  177.  
  178.          MULTICS.MIT.EDU
  179.          TAC.MIT.EDU
  180.          XX.MIT.EDU
  181.  
  182.    The CSNET Domain
  183.  
  184.       There may be a consortium of universities and industry research
  185.       laboratories called, say, "CSNET".  This CSNET is not a network
  186.       per se, but rather a computer mail exchange using a variety of
  187.       protocols and network systems.  Therefore, CSNET is not a network
  188.       in the sense of the ARPANET, or an Ethernet, or even the
  189.       ARPA-Internet, but rather a community.  Yet it does, in fact, have
  190.       the key property needed to form a domain; it has a responsible
  191.       administration.  This consortium might be large enough and might
  192.       have membership that cuts across the categories in such a way that
  193.       it qualifies under the "multiorganization rule" to be a top level
  194.       domain.
  195.  
  196.       One might see domain style names for hosts in this domain like
  197.       these:
  198.  
  199.          CIC.CSNET
  200.          EMORY.CSNET
  201.          GATECH.CSNET
  202.          HP-LABS.CSNET
  203.          SJ.IBM.CSNET
  204.          UDEL.CSNET
  205.          UWISC.CSNET
  206.  
  207. General Requirements on a Domain
  208.  
  209.    There are several requirements that must be met to establish a
  210.    domain.  In general, it must be responsibly managed.  There must be a
  211.    responsible person to serve as an authoritative coordinator for
  212.    domain related questions.  There must be a robust domain name lookup
  213.    service, it must be of at least a minimum size, and the domain must
  214.    be registered with the central domain administrator (the Network
  215.    Information Center (NIC) Domain Registrar).
  216.  
  217.    Responsible Person:
  218.  
  219.       An individual must be identified who has authority for the
  220.       administration of the names within the domain, and who seriously
  221.       takes on the responsibility for the behavior of the hosts in the
  222.       domain, plus their interactions with hosts outside the domain.
  223.       This person must have some technical expertise and the authority
  224.       within the domain to see that problems are fixed.
  225.  
  226.  
  227. Postel & Reynolds                                               [Page 4]
  228.  
  229.  
  230.  
  231. RFC 920                                                     October 1984
  232. Domain Requirements
  233.  
  234.  
  235.       If a host in a given domain somehow misbehaves in its interactions
  236.       with hosts outside the domain (e.g., consistently violates
  237.       protocols), the responsible person for the domain must be
  238.       competent and available to receive reports of problems, take
  239.       action on the reported problems, and follow through to eliminate
  240.       the problems.
  241.  
  242.    Domain Servers:
  243.  
  244.       A robust and reliable domain server must be provided.  One way of
  245.       meeting this requirement is to provide at least two independent
  246.       domain servers for the domain.  The database can, of course, be
  247.       the same.  The database can be prepared and copied to each domain
  248.       server.  But, the servers should be in separate machines on
  249.       independent power supplies, et cetera; basically as physically
  250.       independent as can be.  They should have no common point of
  251.       failure.
  252.  
  253.       Some domains may find that providing a robust domain service can
  254.       most easily be done by cooperating with another domain where each
  255.       domain provides an additional server for the other.
  256.  
  257.       In other situations, it may be desirable for a domain to arrange
  258.       for domain service to be provided by a third party, perhaps on
  259.       hosts located outside the domain.
  260.  
  261.       One of the difficult problems in operating a domain server is the
  262.       acquisition and maintenance of the data.  In this case, the data
  263.       are the host names and addresses.  In some environments this
  264.       information changes fairly rapidly and keeping up-to-date data may
  265.       be difficult.  This is one motivation for sub-domains.  One may
  266.       wish to create sub-domains until the rate of change of the data in
  267.       a sub-domain domain server database is easily managed.
  268.  
  269.       In the technical language of the domain server implementation the
  270.       data is divided into zones.  Domains and zones are not necessarily
  271.       one-to-one.  It may be reasonable for two or more domains to
  272.       combine their data in a single zone.
  273.  
  274.       The responsible person or an identified technical assistant must
  275.       understand in detail the procedures for operating a domain server,
  276.       including the management of master files and zones.
  277.  
  278.       The operation of a domain server should not be taken on lightly.
  279.       There are some difficult problems in providing an adequate
  280.       service, primarily the problems in keeping the database up to
  281.       date, and keeping the service operating.
  282.  
  283.  
  284. Postel & Reynolds                                               [Page 5]
  285.  
  286.  
  287.  
  288. RFC 920                                                     October 1984
  289. Domain Requirements
  290.  
  291.  
  292.       The concepts and implementation details of the domain server are
  293.       given in RFC-882 [2] and RFC-883 [3].
  294.  
  295.    Minimum Size:
  296.  
  297.       The domain must be of at least a minimum size.  There is no
  298.       requirement to form a domain because some set of hosts is above
  299.       the minimum size.
  300.  
  301.       Top level domains must be specially authorized.  In general, they
  302.       will only be authorized for domains expected to have over 500
  303.       hosts.
  304.  
  305.       The general guideline for a second level domain is that it have
  306.       over 50 hosts.  This is a very soft "requirement".  It makes sense
  307.       that any major organization, such as a university or corporation,
  308.       be allowed as a second level domain -- even if it has just a few
  309.       hosts.
  310.  
  311.    Registration:
  312.  
  313.       Top level domains must be specially authorized and registered with
  314.       the NIC domain registrar.
  315.  
  316.       The administrator of a level N domain must register with the
  317.       registrar (or responsible person) of the level N-1 domain.  This
  318.       upper level authority must be satisfied that the requirements are
  319.       met before authorization for the domain is granted.
  320.  
  321.       The registration procedure involves answering specific questions
  322.       about the prospective domain.  A prototype of what the NIC Domain
  323.       Registrar may ask for the registration of a second level domain is
  324.       shown below.  These questions may change from time to time.  It is
  325.       the responsibility of domain administrators to keep this
  326.       information current.
  327.  
  328.       The administrator of a domain is required to make sure that host
  329.       and sub-domain names within that jurisdiction conform to the
  330.       standard name conventions and are unique within that domain.
  331.  
  332.       If sub-domains are set up, the administrator may wish to pass
  333.       along some of his authority and responsibility to a sub-domain
  334.       administrator.  Even if sub-domains are established, the
  335.       responsible person for the top-level domain is ultimately
  336.       responsible for the whole tree of sub-domains and hosts.
  337.  
  338.       This does not mean that a domain administrator has to know the
  339.  
  340.  
  341. Postel & Reynolds                                               [Page 6]
  342.  
  343.  
  344.  
  345. RFC 920                                                     October 1984
  346. Domain Requirements
  347.  
  348.  
  349.       details of all the sub-domains and hosts to the Nth degree, but
  350.       simply that if a problem occurs he can get it fixed by calling on
  351.       the administrator of the sub-domain containing the problem.
  352.  
  353. Top Level Domain Requirements
  354.  
  355.    There are very few top level domains, each of these may have many
  356.    second level domains.
  357.  
  358.    An initial set of top level names has been identified.  Each of these
  359.    has an administrator and an agent.
  360.  
  361.    The top level domains:
  362.  
  363.       ARPA =  The ARPA-Internet   *** TEMPORARY ***
  364.  
  365.          Administrator:  DARPA
  366.          Agent:          The Network Information Center
  367.          Mailbox:        HOSTMASTER@SRI-NIC.ARPA
  368.  
  369.       GOV  =  Government
  370.  
  371.          Administrator:  DARPA
  372.          Agent:          The Network Information Center
  373.          Mailbox:        HOSTMASTER@SRI-NIC.ARPA
  374.  
  375.       EDU  =  Education
  376.  
  377.          Administrator:  DARPA
  378.          Agent:          The Network Information Center
  379.          Mailbox:        HOSTMASTER@SRI-NIC.ARPA
  380.  
  381.       COM  =  Commercial
  382.  
  383.          Administrator:  DARPA
  384.          Agent:          The Network Information Center
  385.          Mailbox:        HOSTMASTER@SRI-NIC.ARPA
  386.  
  387.       MIL  =  Military
  388.  
  389.          Administrator:  DDN-PMO
  390.          Agent:          The Network Information Center
  391.          Mailbox:        HOSTMASTER@SRI-NIC.ARPA
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398. Postel & Reynolds                                               [Page 7]
  399.  
  400.  
  401.  
  402. RFC 920                                                     October 1984
  403. Domain Requirements
  404.  
  405.  
  406.       ORG  =  Organization
  407.  
  408.          Administrator:  DARPA
  409.          Agent:          The Network Information Center
  410.          Mailbox:        HOSTMASTER@SRI-NIC.ARPA
  411.  
  412.       Countries
  413.  
  414.          The English two letter code (alpha-2) identifying a country
  415.          according the the ISO Standard for "Codes for the
  416.          Representation of Names of Countries" [5].
  417.  
  418.          As yet no country domains have been established.  As they are
  419.          established information about the administrators and agents
  420.          will be made public, and will be listed in subsequent editions
  421.          of this memo.
  422.  
  423.       Multiorganizations
  424.  
  425.          A multiorganization may be a top level domain if it is large,
  426.          and is composed of other organizations; particularly if the
  427.          multiorganization can not be easily classified into one of the
  428.          categories and is international in scope.
  429.  
  430.          As yet no multiorganization domains have been established.  As
  431.          they are established information about the administrators and
  432.          agents will be made public, and will be listed in subsequent
  433.          editions of this memo.
  434.  
  435.       Note:  The NIC is listed as the agent and registrar for all the
  436.       currently allowed top level domains.  If there are other entities
  437.       that would be more appropriate agents and registrars for some or
  438.       all of these domains then it would be desirable to reassign the
  439.       responsibility.
  440.  
  441. Second Level Domain Requirements
  442.  
  443.    Each top level domain may have many second level domains.  Every
  444.    second level domain must meet the general requirements on a domain
  445.    specified above, and be registered with a top level domain
  446.    administrator.
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455. Postel & Reynolds                                               [Page 8]
  456.  
  457.  
  458.  
  459. RFC 920                                                     October 1984
  460. Domain Requirements
  461.  
  462.  
  463. Third through Nth Level Domain Requirements
  464.  
  465.    Each second level domain may have many third level domains, etc.
  466.    Every third level domain (through Nth level domain) must meet the
  467.    requirements set by the administrator of the immediately higher level
  468.    domain.  Note that these may be more or less strict than the general
  469.    requirements.  One would expect the minimum size requirements to
  470.    decrease at each level.
  471.  
  472. The ARPA Domain
  473.  
  474.    At the time the implementation of the domain concept was begun it was
  475.    thought that the set of hosts under the administrative authority of
  476.    DARPA would make up a domain.  Thus the initial domain selected was
  477.    called ARPA.  Now it is seen that there is no strong motivation for
  478.    there to be a top level ARPA domain.  The plan is for the current
  479.    ARPA domain to go out of business as soon as possible.  Hosts that
  480.    are currently members of the ARPA domain should make arrangements to
  481.    join another domain.  It is likely that for experimental purposes
  482.    there will be a second level domain called ARPA in the ORG domain
  483.    (i.e., there will probably be an ARPA.ORG domain).
  484.  
  485. The DDN Hosts
  486.  
  487.    DDN hosts that do not desire to participate in this domain naming
  488.    system will continue to use the HOSTS.TXT data file maintained by the
  489.    NIC for name to address translations.  This file will be kept up to
  490.    date for the DDN hosts.  However, all DDN hosts will change their
  491.    names from "host.ARPA" to (for example) "host.DDN.MIL" some time in
  492.    the future.  The schedule for changes required in DDN hosts will be
  493.    established by the DDN-PMO.
  494.  
  495. Impact on Hosts
  496.  
  497.    What is a host administrator to do about all this?
  498.  
  499.       For existing hosts already operating in the ARPA-Internet, the
  500.       best advice is to sit tight for now.  Take a few months to
  501.       consider the options, then select a domain to join.  Plan
  502.       carefully for the impact that changing your host name will have on
  503.       both your local users and on their remote correspondents.
  504.  
  505.       For a new host, careful thought should be given (as discussed
  506.       below).  Some guidance can be obtained by comparing notes on what
  507.       other hosts with similar administrative properties have done.
  508.  
  509.    The owner of a host may decide which domain to join, and the
  510.  
  511.  
  512. Postel & Reynolds                                               [Page 9]
  513.  
  514.  
  515.  
  516. RFC 920                                                     October 1984
  517. Domain Requirements
  518.  
  519.  
  520.    administrator of a domain may decide which hosts to accept into his
  521.    domain.  Thus the owner of a host and a domain administrator must
  522.    come to an understanding about the host being in the domain.  This is
  523.    the foundation of responsible administration.
  524.  
  525.       For example, a host "XYZ" at MIT might possible be considered as a
  526.       candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or
  527.       XYZ.MIT.EDU.
  528.  
  529.          The owner of host XYZ may choose which domain to join,
  530.          depending on which domain administrators are willing to have
  531.          him.
  532.  
  533.    The domain is part of the host name.  Thus if USC-ISIA.ARPA changes
  534.    its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has
  535.    changed its name.  This means that any previous references to
  536.    USC-ISIA.ARPA are now out of date.  Such old references may include
  537.    private host name to address tables, and any recorded information
  538.    about mailboxes such as mailing lists, the headers of old messages,
  539.    printed directories, and peoples' memories.
  540.  
  541.    The experience of the DARPA community suggests that changing the name
  542.    of a host is somewhat painful.  It is recommended that careful
  543.    thought be given to choosing a new name for a host - which includes
  544.    selecting its place in the domain hierarchy.
  545.  
  546. The Roles of the Network Information Center
  547.  
  548.    The NIC plays two types of roles in the administration of domains.
  549.    First,  the NIC is the registrar of all top level domains.  Second
  550.    the NIC is the administrator of several top level domains (and the
  551.    registrar for second level domains in these).
  552.  
  553.    Top Level Domain Registrar
  554.  
  555.       As the registrar for top level domains, the NIC is the contact
  556.       point for investigating the possibility of establishing a new top
  557.       level domain.
  558.  
  559.    Top Level Domain Administrator
  560.  
  561.       For the top level domains designated so far, the NIC is the
  562.       administrator of each of these domains.  This means the NIC is
  563.       responsible for the management of these domains and the
  564.       registration of the second level domains or hosts (if at the
  565.       second level) in these domains.
  566.  
  567.  
  568.  
  569. Postel & Reynolds                                              [Page 10]
  570.  
  571.  
  572.  
  573. RFC 920                                                     October 1984
  574. Domain Requirements
  575.  
  576.  
  577.       It may be reasonable for the administration of some of these
  578.       domains to be taken on by other authorities in the future.  It is
  579.       certainly not desired that the NIC be the administrator of all top
  580.       level domains forever.
  581.  
  582. Prototypical Questions
  583.  
  584.    To establish a domain, the following information must be provided to
  585.    the NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
  586.  
  587.       Note:  The key people must have computer mail mailboxes and
  588.       NIC-Idents.  If they do not at present, please remedy the
  589.       situation at once.  A NIC-Ident may be established by contacting
  590.       NIC@SRI-NIC.ARPA.
  591.  
  592.    1)  The name of the top level domain to join.
  593.  
  594.       For example:  EDU
  595.  
  596.    2)  The name, title, mailing address, phone number, and organization
  597.    of the administrative head of the organization.  This is the contact
  598.    point for administrative and policy questions about the domain.  In
  599.    the case of a research project, this should be the Principal
  600.    Investigator.  The online mailbox and NIC-Ident of this person should
  601.    also be included.
  602.  
  603.       For example:
  604.  
  605.          Administrator
  606.  
  607.             Organization  USC/Information Sciences Institute
  608.             Name          Keith Uncapher
  609.             Title         Executive Director
  610.             Mail Address  USC/ISI
  611.                           4676 Admiralty Way, Suite 1001
  612.                           Marina del Rey, CA. 90292-6695
  613.             Phone Number  213-822-1511
  614.             Net Mailbox   Uncapher@USC-ISIB.ARPA
  615.             NIC-Ident     KU
  616.  
  617.    3)  The name, title, mailing address, phone number, and organization
  618.    of the domain technical contact.  The online mailbox and NIC-Ident of
  619.    the domain technical contact should also be included.  This is the
  620.    contact point for problems with the domain and for updating
  621.    information about the domain.  Also, the domain technical contact may
  622.    be responsible for hosts in this domain.
  623.  
  624.  
  625.  
  626. Postel & Reynolds                                              [Page 11]
  627.  
  628.  
  629.  
  630. RFC 920                                                     October 1984
  631. Domain Requirements
  632.  
  633.  
  634.       For example:
  635.  
  636.          Technical Contact
  637.  
  638.             Organization  USC/Information Sciences Institute
  639.             Name          Craig Milo Rogers
  640.             Title         Researcher
  641.             Mail Address  USC/ISI
  642.                           4676 Admiralty Way, Suite 1001
  643.                           Marina del Rey, CA. 90292-6695
  644.             Phone Number  213-822-1511
  645.             Net Mailbox   Rogers@USC-ISIB.ARPA
  646.             NIC-Ident     CMR
  647.  
  648.    4)  The name, title, mailing address, phone number, and organization
  649.    of the zone technical contact.  The online mailbox and NIC-Ident of
  650.    the zone technical contact should also be included.  This is the
  651.    contact point for problems with the zone and for updating information
  652.    about the zone.  In many cases the zone technical contact and the
  653.    domain technical contact will be the same person.
  654.  
  655.       For example:
  656.  
  657.          Technical Contact
  658.  
  659.             Organization  USC/Information Sciences Institute
  660.             Name          Craig Milo Rogers
  661.             Title         Researcher
  662.             Mail Address  USC/ISI
  663.                           4676 Admiralty Way, Suite 1001
  664.                           Marina del Rey, CA. 90292-6695
  665.             Phone Number  213-822-1511
  666.             Net Mailbox   Rogers@USC-ISIB.ARPA
  667.             NIC-Ident     CMR
  668.  
  669.    5)  The name of the domain (up to 12 characters).  This is the name
  670.    that will be used in tables and lists associating the domain and the
  671.    domain server addresses.  [While technically domain names can be
  672.    quite long (programmers beware), shorter names are easier for people
  673.    to cope with.]
  674.  
  675.       For example:  ALPHA-BETA
  676.  
  677.    6)  A description of the servers that provides the domain service for
  678.    translating name to address for hosts in this domain, and the date
  679.    they will be operational.
  680.  
  681.  
  682.  
  683. Postel & Reynolds                                              [Page 12]
  684.  
  685.  
  686.  
  687. RFC 920                                                     October 1984
  688. Domain Requirements
  689.  
  690.  
  691.       A good way to answer this question is to say "Our server is
  692.       supplied by person or company X and does whatever their standard
  693.       issue server does".
  694.  
  695.          For example:  Our server is a copy of the server operated by
  696.          the NIC, and will be installed and made operational on
  697.          1-November-84.
  698.  
  699.    7)  A description of the server machines, including:
  700.  
  701.       (a) hardware and software (using keywords from the Assigned
  702.       Numbers)
  703.  
  704.       (b) addresses (what host on what net for each connected net)
  705.  
  706.       For example:
  707.  
  708.          (a) hardware and software
  709.  
  710.             VAX-11/750  and  UNIX,    or
  711.             IBM-PC      and  MS-DOS,  or
  712.             DEC-1090    and  TOPS-20
  713.  
  714.          (b) address
  715.  
  716.             10.9.0.193 on ARPANET
  717.  
  718.    8)  An estimate of the number of hosts that will be in the domain.
  719.  
  720.       (a) initially,
  721.       (b) within one year,
  722.       (c) two years, and
  723.       (d) five years.
  724.  
  725.       For example:
  726.  
  727.          (a) initially  =   50
  728.          (b) one year   =  100
  729.          (c) two years  =  200
  730.          (d) five years =  500
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740. Postel & Reynolds                                              [Page 13]
  741.  
  742.  
  743.  
  744. RFC 920                                                     October 1984
  745. Domain Requirements
  746.  
  747.  
  748. Acknowledgment
  749.  
  750.    We would like to thank the many people who contributed to this memo,
  751.    including the participants in the Namedroppers Group, the ICCB, the
  752.    PCCB, and especially the staff of the Network Information Center,
  753.    particularly J. Feinler and K. Harrenstien.
  754.  
  755. References
  756.  
  757.    [1]  Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
  758.         Information Sciences Institute, November 1983.
  759.  
  760.    [2]  Mockapetris, P., "Domain Names - Concepts and Facilities",
  761.         RFC-882, USC Information Sciences Institute, November 1983.
  762.  
  763.    [3]  Mockapetris, P., "Domain Names - Implementation and
  764.         Specification", RFC-883, USC Information Sciences Institute,
  765.         November 1983.
  766.  
  767.    [4]  Postel, J., "Domain Name System Implementation Schedule",
  768.         RFC-897, USC Information Sciences Institute, February 1984.
  769.  
  770.    [5]  ISO, "Codes for the Representation of Names of Countries",
  771.         ISO-3166, International Standards Organization, May 1981.
  772.  
  773.    [6]  Postel, J., "Domain Name System Implementation Schedule -
  774.         Revised", RFC-921, USC Information Sciences Institute, October
  775.         1984.
  776.  
  777.    [7]  Mockapetris, P., "The Domain Name System", Proceedings of the
  778.         IFIP 6.5 Working Conference on Computer Message Services,
  779.         Nottingham, England, May 1984.  Also as ISI/RS-84-133,
  780.         June 1984.
  781.  
  782.    [8]  Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design
  783.         for Distributed Systems", Proceedings of the Seventh
  784.         International Conference on Computer Communication, October 30
  785.         to November 3 1984, Sidney, Australia.  Also as ISI/RS-84-132,
  786.         June 1984.
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797. Postel & Reynolds                                              [Page 14]
  798.  
  799.